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DETAILED ACTION 

1 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 1-7 and 9-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Champagne 
(US 7,310,730 Bl) in view of Voit (US 6,798,751 Bl). 

Regarding claim 1 

Referring to claim 1 Champagne discloses a method in an intermediate node comprising a 
multicast/broadcast server and a streaming node for providing multicast for streaming 
transmission from a streaming server to users of a multicast group with the multicast/broadcast 
server providing multicast transmission and with the streaming node providing a streaming 
transmission based on an on-demand single -user signaling supporting the transmission of a 
streaming flow, the method comprising the steps of (Abstract: A method of communicating an 
encrypted data broadcast to a plurality of virtual private network receivers is disclosed. A first 
communication channel is established between a first one of the receivers and a network node. A 
private data stream is communicated to the first receiver on the first channel. A request is 
received from the first receiver to join a broadcast data stream that is directed to a plurality of 
receivers by a broadcast server. A second encrypted communication channel is established 
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between the first receiver and the network node for purposes of carrying the broadcast data 
stream. Decryption information, which the first receiver can use to decrypt information that is 
sent on the second channel, is sent to the first receiver through the first channel. The broadcast 
data stream is then communicated to the first receiver on the second channel. As a result, a 
particular receiver can receive an encrypted broadcast that is encrypted as part of a single session 
for a large plurality of other receivers, without impacting separate, private encrypted 
communications conducted by the particular receiver.) (Col. 6 lines 8-18 In block 306, a request 
from the first receiver to join a broadcast is received. The request may be an HTTP or RTSP 
request. For example, network node 202 receives a request from VPN client 214B to join a 
broadcast data stream originating at broadcast server 102. VPN client 214B may provide the 
request to the network node 202 by relaying a selection of a link or UR-L associated with 
broadcast server 102 that is made by an end user at personal computer 1 16B. In this context, a 
"broadcast" or "broadcast event" refers to an event that ideally is multicasted, such as live 
streaming audio, video streaming, etc.) and (Fig. 2): establishing a bearer for a multicast 
transmission according to the requirements for streaming transmission (Col. 7 lines 1 1-22 In 
one particular approach, the broadcast event is unicast to each receiver using IPSec for 
encryption on the broadcast channel. Alternatively, the broadcasted event can be transmitted 
using generic routing encapsulation (GRE). In this approach, the broadcast server 102 
communicates the broadcast using multicast to all elements of LAN 104 or network 108 that 
support multicast, and uses unicast GRE tunnels for communication to clients through elements 
that do not support multicast. In this approach, for efficiency, the network element that originates 
the unicast streams could cache the broadcast stream.), establishing a multi-user streaming 
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session on the bearer by translating the on - demand ( e.g. Video -On-Demand) single -user 
signaling received from the streaming server into multi-user push signaling ( Col. 7 lines 33-36 
In this environment, the ISP could store the broadcast event as a confidential file in a cache local 
to a particular set of users. Such users then could retrieve, as Video-On-Demand, the broadcast 
event stored in the cache, which would be sent by unicast to the users.). Champagne did not 
discloses adapting the received streaming flow to the multicast transmission according to the 
needs of a multicast group or subgroup of a multicast group, replicating the received streaming 
transmission according to the number of the multicast subgroups. The general concept of 
adapting the received streaming flow to the multicast transmission according to the needs of a 
multicast group or subgroup of a multicast group, replicating the received streaming transmission 
according to the number of the multicast subgroups is well known in the art as taught by Voit. 
Voit discloses adapting the received streaming flow to the multicast transmission according to 
the needs of a multicast group or subgroup of a multicast group, replicating the received 
streaming transmission according to the number of the multicast subgroups. (Col. 25 lines 45 -56 
and Col 26 lines 1-6 For a multicast service, such as the satellite -originated video broadcast 
service, the service provider sends one stream through the vertical services domain network 13 to 
the L3/4 ATM switch 19. The switch 19 will monitor every ATM virtual circuit going to the 
subscribers, looking for IGNP requests. A subscriber sends an IGNP request to join a selected 
multicast channel. When the L3/4 ATM switch 19 detects such a request, it identifies the 
requested channel and the requesting subscriber equipment and forwards a "join" message to the 
vertical services domain. Subsequently, the switch 19 replicates received packets for the 
requested broadcast channel, and the switch drops the replicated packets into the cells for each of 
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the virtual circuits of all of the joined subscribers, including the newly added subscriber. When 
the subscriber later elects to end viewing of the multicast, the subscriber's equipment sends a 
"leave" message, and the switch 19 stops adding the cells for the multicast to that subscriber's 
virtual circuit). It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify Champagne to include adapting the received streaming flow to the multicast 
transmission according to the needs of a multicast group or subgroup of a multicast group, 
replicating the received streaming transmission according to the number of the multicast 
subgroups in order to provide any bandwidth or delay guarantees 

Regarding claims 15 and 16 

Claims 15 and 16 are similarly rejected using at least the same reasoning /citations provided for 
claim 1 since they recite the same limitations and are distinguished only by statutory category. 

Regarding claim 2 

Referring to claim 2 Champagne and Voit discloses all the limitations of claim 2 which is 
described above. Champagne also discloses further comprising the step of the streaming node 
communicating with the server adapts the streaming transmission and forwards the adapted 
streaming transmission to the multicast/ broadcast server (Col. 7 lines 1 1-22 In one particular 
approach, the broadcast event is unicast to each receiver using IPSec for encryption on the 
broadcast channel. Alternatively, the broadcasted event can be transmitted using generic routing 



Application/Control Number: 10/595,473 Page 6 

Art Unit: 2154 

encapsulation (GRE). In this approach, the broadcast server 102 communicates the broadcast 
using multicast to all elements of LAN 104 or network 108 that support multicast, and uses 
unicast GRE tunnels for communication to clients through elements that do not support 
multicast. In this approach, for efficiency, the network element that originates the unicast streams 
could cache the broadcast stream). Champagne did not discloses which replicates the received 
streaming transmission among subgroups of a multicast group. The general concept of replicates 
the received streaming transmission among subgroups of a multicast group is well known in the 
art as taught by Voit. Voit discloses replicates the received streaming transmission among 
subgroups of a multicast group (Col. 25 lines 45 -56 and Col 26 lines 1-6 For a multicast service, 
such as the satellite-originated video broadcast service, the service provider sends one stream 
through the vertical services domain network 13 to the L3/4 ATM switch 19. The switch 19 will 
monitor every ATM virtual circuit going to the subscribers, looking for IGNP requests. A 
subscriber sends an IGNP request to join a selected multicast channel. When the L3/4 ATM 
switch 19 detects such a request, it identifies the requested channel and the requesting subscriber 
equipment an d forwards a 'join" message to the vertical services domain. Subsequently, the 
switch 19 replicates received packets for the requested broadcast channel, and the switch drops 
the replicated p ackets into the cells for each of the virtual circuits of all of the joined subscribers, 
including the newly added subscriber. When the subscriber later elects to end viewing of the 
multicast, the subscriber's equipment sends a Teave' message, and the switch 19 stops adding the 
cells for the multicast to that subscriber's virtual circuit). It would have been obvious to one of 
ordinary skill in the art at the time of the invention to modify Champagne to include replicates 
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the received streaming transmission among subgroups of a multicast group in order to provide 
any bandwidth or delay guarantees. 

Regarding claim 3 

Referring to claim 3 Champagne and Voit discloses all the limitations of claim 3 which is 
described above. Champagne also discloses the multicast/broadcast server i.e. server 102 
communicating with the server i.e. server 103 (Fig.2). Champagne did not discloses replicates 
the received streaming transmission among the subgroups of a multicast group and forwards 
each replicated streaming transmission to the streaming node, which adapts each streaming 
transmission. The general concept of replicates the received streaming transmission among the 
subgroups of a multicast group and forwards each replicated streaming transmission to the 
streaming node, which adapts each streaming transmission is well known in the art as taught by 
Voit. Voit discloses replicates the received streaming transmission among the subgroups of a 
multicast group and forwards each replicated streaming transmission to the streaming node, 
which adapts each streaming transmission. (Col. 25 lines 45 -56 and Col 26 lines 1-6 For a 
multicast service, such as the satellite-originated video broadcast service, the service provider 
sends one stream through the vertical services domain network 13 to the L3/4 ATM switch 19. 
The switch 19 will monitor every ATM virtual circuit going to the subscribers, looking for IGNP 
requests. A subscriber sends an IGNP request to join a selected multicast channel. When the 
L3/4 ATM switch 19 detects such a request, it identifies the requested channel and the requesting 
subscriber equipment an d forwards a 'join" message to the vertical services domain. 
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Subsequently, the switch 19 replicates received packets for the requested broadcast channel, and 
the switch drops the replicated p ackets into the cells for each of the virtual circuits of all of the 
joined subscribers, including the newly added subscriber. When the subscriber later elects to end 
viewing of the multicast, the subscriber's equipment sends a ' leave' message, and the switch 19 
stops adding the cells for the multicast to that subscriber's virtual circuit). It would have been 
obvious to one of ordinary skill in the art at the time of the invention to modify Champagne to 
include replicates the received streaming transmission among the subgroups of a multicast group 
and forwards each replicated streaming transmission to the streaming node, which adapts each 
streaming transmission in order to provide any bandwidth or delay guarantees. 

Regarding claim 4 

Referring to claim 4 Champagne and Voit discloses all the limitations of claim 4 which is 
described above. Champagne also discloses wherein a decision unit is provided for deciding how 
the received streaming flow is to be directed in the intermediate node. (Col. 7 lines 1 1-22 In one 
particular approach, the broadcast event is unicast to each receiver using IPSec for encryption on 
the broadcast channel. Alternatively, the broadcasted event can be transmitted using generic 
routing encapsulation (GRE). In this approach, the broadcast server 102 communicates the 
broadcast using multicast to all elements of LAN 104 or network 108 that support multicast, and 
uses unicast GRE tunnels for communication to clients through elements that do not support 
multicast. In this approach, for efficiency, the network element that originates the unicast streams 
could cache the broadcast stream). 
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Regarding claim 5 

Referring to claim 5 Champagne and Voit discloses all the limitations of claim 5 which is 
described above. Champagne also discloses wherein the streaming nodes have different 
capabilities and the multicast/broadcast server knows the different capabilities and addresses of 
the streaming nodes in order to select an appropriate streaming node for performing an 
appropriate adaptation of the streaming flow. (Col. 7 lines 1 1-22 In one particular approach, the 
broadcast event is unicast to each receiver using IPScc for encryption on the broadcast channel. 
Alternatively, the broadcasted event can be transmitted using generic routing encapsulation 
(GRE). In this approach, the broadcast server 102 communicates the broadcast using multicast to 
all elements of LAN 104 or network 108 that support multicast, and uses unicast GRE tunnels 
for communication to clients through elements that do not support multicast. In this approach, for 
efficiency, the network element that originates the unicast streams could cache the broadcast 
stream.) and ( Col. 7 lines 58-62 In another approach, network node 202 may maintain a table of 
network address of known nodes that send broadcasts. Packets received at network node 202 are 
then examined and a lookup in the table is performed to determine if a broadcast node is sending 
the packets). 



Regarding claim 6 
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Referring to claim 6 Champagne and Voit discloses all the limitations of claim 6 which is 
described above. Champagne also discloses wherein in case a hierarchical coding (e.g. 
encryption) is used the streaming flows are differentiated in sense that a different number of 
layers is sent to different streaming nodes. (Col. 7 lines 47-57 In block 406, a broadcast event is 
detected. For example, network node 202 detects that broadcast server 102 has initiated a 
broadcast. Such detection may be performed using several approaches. For example, if the 
broadcast server 102 is multicasting the broadcast event, the network node may automatically 
detect that such an event requires a common encryption scheme for all VPN users. Alternatively, 
if the broadcast server does not use multicast, the VPN concentrator can detect that a broadcast 
event is occurring from request information in the protocol layers of event packets above the IP 
layer.) and (Col. 8 lines 33-41 The strength of encryption performed by common channel 
encryption engine 220D can vary. For example, the VPN concentrator can implement policy- 
based encryption based on the Layer 3 or Layer 4 attributes of the traffic generated by the 
broadcast server. As a specific example, network node 202 may examine the type of request 
received from the VPN client 214B and determine that for a phone conference meeting, 64-bit 
encryption is used, whereas for a company all-hands meeting, 128-bit encryption is used, etc.) 

Regarding claim 7 

Referring to claim 7 Champagne and Voit discloses all the limitations of claim 7 which is 
described above. Champagne also discloses wherein the intermediate node administrates an 
address identifying the streaming flow arriving from the server. (Col. 7 lines 47-57 In block 406, 
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a broadcast event is detected. For example, network node 202 detects that broadcast server 102 
has initiated a broadcast. Such detection may be performed using several approaches. For 
example, if the broadcast server 102 is multicasting the broadcast event, the network node may 
automatically detect that such an event requires a common encryption scheme for all VPN users. 
Alternatively, if the broadcast server does not use multicast, the VPN concentrator can detect that 
a broadcast event is occurring from request information in the protocol layers of event packets 
above the IP layer.) and ( Col. 7 lines 58-62 In another approach, network node 202 may 
maintain a table of network address of known nodes that send broadcasts. Packets received at 
network node 202 are then examined and a lookup in the table is performed to determine if a 
broadcast node is sending the packets). 

Regarding claim 9 

Referring to claim 9 Champagne and Voit discloses all the limitations of claim 9 which is 
described above. Champagne did not discloses wherein the intermediate node receives a session 
description message informing about the transmission parameters required for the streaming 
session and said intermediate node changes the received parameters according to the needs of the 
subgroups that receive a dedicated replicated stream and sends the changed parameter to the 
group members by means of the multi-user push signaling message. The general concept of 
wherein the intermediate node receives a session description message informing about the 
transmission parameters required for the streaming session and said intermediate node changes 
the received parameters according to the needs of the subgroups that receive a dedicated 
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replicated stream and sends the changed parameter to the group members by means of the multi- 
user push signaling message is well known in the art as taught by Voit. Voit discloses wherein 
the intermediate node receives a session description message informing about the transmission 
parameters required for the streaming session and said intermediate node changes the received 
parameters according to the needs of the subgroups that receive a dedicated replicated stream and 
sends the changed parameter to the group members by means of the multi-user push signaling 
message. (Col. 14 lines 59-67 and Col. 15 lines 1-7 Returning to the discussion of the CO 1 1, 
the structure and operation of each DSLAM 17 is essentially the same as those of the DSLAM 
111 in the embodiment of FIG. 9, except that the control functionality of the DSLAM 17 is 
somewhat different. The DSLAM 17 controls the ATU-Cs to implement a rate-adaptive ADSL 
service, to adapt operations so as to maximize data rates for the communications over the 
individual subscriber lines. Essentially, the ATU-Cs and ATU-Rs signal each other over the lines 
to synchronize their modes of operation at parameter settings, which achieve optimum data 
throughput. Also, the DSLAM 17 does not need to monitor or limit the line rates, but instead 
relies on the rate-adaptive control algorithm to maximize the rates achieved over the ADSL 
circuits or provide rate-shaping for the ATM virtual circuits. Other network elements limit rates, 
where necessary. It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify Champagne to include wherein the intermediate node receives a session 
description message informing about the transmission parameters required for the streaming 
session and said intermediate node changes the received parameters according to the needs of the 
subgroups that receive a dedicated replicated stream and sends the changed parameter to the 
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group members by means of the multi-user push signaling message in order to provide any 
bandwidth or delay guarantees. 

Regarding claim 10 

Referring to claim 10 Champagne and Voit discloses all the limitations of claim 10 which is 
described above. Champagne did not discloses wherein nodes higher up in the hierarchy are 
informed that the streaming flow is only to be forwarded to a single node lower in the hierarchy 
by means of a new message being distribute along the multicast delivery tree. The general 
concept of nodes higher up in the hierarchy are informed that the streaming flow is only to be 
forwarded to a single node lower in the hierarchy by means of a new message being distribute 
along the multicast delivery tree is well known in the art as taught by Voit. Voit discloses nodes 
higher up in the hierarchy are informed that the streaming flow is only to be forwarded to a 
single node lower in the hierarchy by means of a new message being distribute along the 
multicast delivery tree. (Col. 25 lines 45 -56 and Col 26 lines 1-6 For a multicast service, such as 
the satellite-originated video broadcast service, the service provider sends one stream through the 
vertical services domain network 13 to the L3/4 ATM switch 19. The switch 19 will monitor 
every ATM virtual circuit going to the subscribers, looking for IGNP requests. A subscriber 
sends an IGNP request to join a selected multicast channel. When the L3/4 ATM switch 19 
detects such a request, it identifies the requested channel and the requesting subscriber 
equipment an d forwards a 'join message to the vertical services domain. Subsequently, the 
switch 19 replicates received packets for the requested broadcast channel, and the switch drops 
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the replicated p ackets into the cells for each of the virtual circuits of all of the joined subscribers, 
including the newly added subscriber. When the subscriber later elects to end viewing of the 
multicast, the subscriber's equipment sends a 'leave' message, and the switch 19 stops adding the 
cells for the multicast to that subscriber's virtual circuit). It would have been obvious to one of 
ordinary skill in the art at the time of the invention to modify Champagne to include nodes 
higher up in the hierarchy are informed that the streaming flow is only to be forwarded to a 
single node lower in the hierarchy by means of a new message being distribute along the 
multicast delivery tree in order to provide any bandwidth or delay guarantees 

Regarding claim 11 

Referring to claim 1 1 Champagne and Voit discloses all the limitations of claim 1 1 which is 
described above. Champagne also discloses wherein the conversion between single-user on- 
demand and multi-user push signaling implies that certain messages are not propagated. (Col. 1 
lines60-67 and Col 2 lines 1-4 Further, communicating broadcast media information using a 
VPN tunnel may significantly reduce the amount of bandwidth available to the VPN end user for 
other communications. Such end users may need to perform other kinds of communication such 
as email, telnet sessions or HTTP browsing using information that is specific to a particular end 
user. Because broadcast media typically have high bandwidth requirements, communicating such 
broadcasts on a large number of VPN sessions may exceed the maximum available encryption 
throughput of the VPN device. As a result, end users may be unable to communicate the user- 
specific information when a broadcast is in process). 
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Regarding claim 12 

Referring to claim 12 Champagne and Voit discloses all the limitations of claim 12 which is 
described above. Champagne did not discloses wherein the replication of the streaming flow is 
based on an access network, in which users are located or/ and on the geographic area and /or on 
the Quality of Service a subgroup wishes for streaming sessions. The general concept of the 
replication of the streaming flow is based on an access network is well known in the art as taught 
by Voit. Voit discloses the replication of the streaming flow is based on an access network, (Col. 
25 lines 45 -56 and Col 26 lines 1-6 For a multicast service, such as the satellite-originated video 
broadcast service, the service provider sends one stream through the vertical services domain 
network 13 to the L3/4 ATM switch 19. The switch 19 will monitor every ATM virtual circuit 
going to the subscribers, looking for IGNP requests. A subscriber sends an IGNP request to join 
a selected multicast channel. When the L3/4 ATM switch 19 detects such a request, it identifies 
the requested channel and the requesting subscriber equipment and forwards a 'join message to 
the vertical services domain. Subsequently, the switch 1 9 replicates received packets for the 
requested broadcast channel, and the switch drops the replicated packets into the cells for each of 
the virtual circuits of all of the joined subscribers, including the newly added subscriber. When 
the subscriber later elects to end viewing of the multicast, the subscriber's equipment sends a 
"leave" message, and the switch 19 stops adding the cells for the multicast to that subscriber's 
virtual circuit)., in which users are located or/ and on the geographic area and /or on the Quality 
of Service a subgroup wishes for streaming sessions (Col. 35 lines 33-51 FIG. 12 provides a 
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flowchart that summarizes the steps taken by the CPE in forwarding Ethernet frames to the 
ADN. In step 1202, an Ethernet frame is received at one of the interface ports. The Ethernet 
frame encapsulates datagrams. Information related to an upper-layer protocol is extracted, in step 
1204, from the received frame. Examples of such information include the destination IP address 
encapsulated within the Ethernet frame. A set of rules (e.g., a routing table) is consulted to 
determine, in step 1206, what ethertype encapsulation needs to be used based on the extracted 
upper-layer information. Once the ethertype encapsulation method is identified, the datagram is 
rc-cncapsulatcd, in step 1208, using the identified ethertype encapsulation method. Once 
encapsulated, the frame, in step 1210, is forwarded upstream over the ADN. In performing the 
forwarding step (step 1210) the CPE can also consult security access control lists to identify 
permissible connections and sessions and block Ethernet frames when appropriate. Similarly, the 
CPE can also perform the forwarding step in a manner to ensure conformance with any QoS 
parameters associated with the upstream bandwidth.). It would have been obvious of one of 
ordinary skill in the art at the time of the invention to modify Champagne to include wherein the 
replication of the streaming flow is based on an access network, in which users are located or/ 
and on the geographic area and /or on the Quality of Service a subgroup wishes for streaming 
sessions in order to provide any bandwidth or delay guarantees. 

Regarding claim 13 

Referring to claim 13 Champagne and Voit discloses all the limitations of claim 3 which is 
described above. Champagne also discloses wherein the intermediate node requests the actual 
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characteristics of the area in order to adapt the streaming flow accordingly. (Col. 7 lines 1 1-22 In 
one particular approach, the broadcast event is unicast to each receiver using IPSec for 
encryption on the broadcast channel. Alternatively, the broadcasted event can be transmitted 
using generic routing encapsulation (GRE). In this approach, the broadcast server 102 
communicates the broadcast using multicast to all elements of LAN 104 or network 108 that 
support multicast, and uses unicast GRE tunnels for communication to clients through elements 
that do not support multicast. In this approach, for efficiency, the network element that originates 
the unicast streams could cache the broadcast stream). 



Regarding claim 14 

Referring to claim 14 Champagne and Voit discloses all the limitations of claim 3 which is 
described above. Champagne discloses wherein the intermediate node provides additional 
information to the charging /billing server in order to guarantee an accurate charging and /or 
multi-user streaming related charging. (Col. 26 lines 35-52 Although IP-based, the services from 
the vertical services domain 13 may follow any other desirable business model. For example, a 
multicast service provider may contract with the carrier to provide multicast audio (radio-like) 
and/or video (TV-like) services via the vertical services domain. The multicast service provider, 
not the subscribers, would pay the carrier. The multicast service provider may offer any or all of 
the multicast programming to customers on some type pay-per-view basis but would likely offer 
most of the programming service for free or bundled in as part of some nominal monthly 
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subscription charge . The multicast service provider instead would charge advertisers in a manner 
analogous to current broadcast business practices. Advertising distributed with the IP 
multicasting, however, can be carefully targeted at end-customers having demographic profiles 
meeting specific criteria specified by individual advertisers, which allows the multicast service 
provider to charge premium advertising rates. ) and (Col. 26 lines 16-34 In an enhanced service 
offering, the broadcast provider could offer a convenient navigation interface from a web server. 
The server could be on the vertical services network, but preferably is on the wide area Internet 
1 1 . With a PPPoE session active, the user can surf to the provider's server and view information 
about available programming. The user might select a current broadcast program by 'clicking" on 
a URL link in the provider's web-based information. Although provided through the wide area 
Internet 1 1 , the URL would actually contain the private IP address for the desired broadcast 
program available from the vertical services network 13. Selection of such a URL therefore 
would generate a message to the appropriate server on the vertical services network 1 1 to initiate 
the above discussed procedure to allow the user to johf the selected broadcast. A similar 
methodology might also enable a provider to offer menu, selection and order/billing services 
from the Internet 1 1 , to provide pay-per-view or video on-demand type services from the vertical 
services domain network 13). It would have been obvious to one of ordinary skill in the art at the 
time of the invention to modify Champagne to include the intermediate node provides additional 
information to the charging /billing server in order to guarantee an accurate charging and /or 
multi-user streaming related charging in order to provide any bandwidth or delay guarantees. 
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Claim 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over Champagne (US 
7,310,730 Bl) in view of Voit (US 6,798,75 1 Bl) further in view of Cannon (US 6,014,706). 



Regarding claim 8 

Referring to claim 8 Champagne and Voit discloses all the limitations of claim 8 which is 
described above. Champagne did not discloses wherein the intermediate node receives a session 
description message informing about the transmission parameters required for the streaming 
session and forwards the received parameters to the group members by means of the multi-user 
push signaling message. The general concept of wherein the intermediate node receives a session 
description message informing about the transmission parameters required for the streaming 
session and forwards the received parameters to the group members by means of the multi-user 
push signaling message is well known in the art as taught by Cannon. Cannon discloses wherein 
the intermediate node receives a session description message informing about the transmission 
parameters required for the streaming session and forwards the received parameters to the group 
members by means of the multi-user push signaling message In a particularly advantageous 
embodiment, the fast forward stream is employed for fast forwarding. The steps taken by the 
server to ascertain the first data packet of the fast forward stream to send when transitioning from 
the real-time play mode (or other modes except live play) to the fast forward mode are depicted 
in FIG. 8. In step 802, the server seeks back in the fast forward stream from the video frame 
whose time corresponds or most closely corresponds to the time parameter sent from the client to 
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the server in step 502 for the first frame to be sent. Alternatively, the server may seek forward in 
the fast forward stream from the video frame whose time corresponds or most closely 
corresponds to the time parameter sent from the client to the server in step 502 for the first frame 
to be sent. The fast forward stream, like the play stream, are stored in the server as the recording 
session progresses as video files. It would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify Champagne to include wherein the intermediate node 
receives a session description message informing about the transmission parameters required for 
the streaming session and forwards the received parameters to the group members by means of 
the multi-user push signaling message in order to provide any bandwidth or delay guarantees. 

Conclusion 

Arguments are deemed moot in view of the new grounds of rejection necessitated by the 
amendment. 

Applicant's amendment necessitated the new ground(s) of rejection presented in this Office 
action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is 
reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
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CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ashley D. Turner whose telephone number is 571-270-1603. The 
examiner can normally be reached on Monday thru Friday 7:30a.m.- 5:00p.m.. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Nathan J. Flynn can be reached on 571-272-1915. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Ashley D Turner 
Examiner 
Art Unit 2154 

/Nathan J. Flynn/ 

Supervisory Patent Examiner, Art Unit 2154 
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